The digital revolution of the late 20th century and the early 21st century has led to the increasing use of digital means of communications. Emails and other similar forms of communications have become the de facto means for non-verbal communications between people. However, this increase in digital communications has also increased the attention given to authenticating such digital communications.
A number of companies have emerged which have operated in the digital communications authentication field. However, these companies need to address not merely the authentication aspect of the issue but also the accessibility aspect of the issue.
Consider a company whose clients are mobile users who may sometimes use desktop computers. Sometimes these clients use laptops or smart phones, and sometimes they use tablets. The company wishes to offer a digital signature service to these clients, so that a client can sign a document and anyone else (i.e., other clients, or members of any other group including the general public) can verify that the signature is valid. It should be noted that the clients or individuals that use the digital signature service provided by the company may be members of the general public. Because each of the users of the service may have different devices with which they may want to access the service, it is not reasonable to require these users to install company-specific software applications on all their devices. As well, it is not practical to insist that clients interact with a 3rd-party Certification Authority (CA) to obtain a cryptographic key pair and a public key certificate suitable for verifying digital signatures prior to using the company's services.
A client's use of multiple devices therefore places some constraints on possible solutions to the authentication issue. In particular, the private signing key cannot be stored on one of the devices—storing the private key on only one device means that the key would not be available for the creation of signatures on the other devices. Simultaneously storing the private key on all the devices is also not advisable since it would be difficult to keep all the keys synchronized whenever key pairs are updated. Additionally, storing a secret or private key in multiple places increases the risk that the key may be compromised.
It should be noted that another option, that of storing the private key at the company's server, is not a viable solution for true, legally-binding digital signatures. This is because there must be convincing evidence that the signing key is known only to the signer and no one else. Such a scheme can therefore only work if the key is encrypted before storage on the company's server and only with a strong encryption key known only to the client. Given this requirement, it would therefore be difficult to generate, remember, and manage such an encryption key at the client's end.
One direction that has been considered in this area is the use of a biometric as this is sufficiently unique per user to distinguish him/her from others in a given population. Unfortunately, every biometric suffers from false positives and false negatives (e.g. some other user gets misidentified as Alice, or Alice gets misidentified as not-Alice), which can severely limit the repeatability of the key generation process. Furthermore, JavaScript code downloaded from a website is typically prevented by the browser from accessing the camera (i.e., for picture or video), microphone (i.e., for voice), or additional hardware components (e.g., for fingerprints) on devices. Even if such an access was possible (e.g., with newer versions of browsers and evolving standards such as HTML5), the quality of the microphone and camera on typical phones and tablets, and the environment in which they are used, would probably not provide a suitable input for a good, reliable biometrics. Similarly, JavaScript code can access mouse clicks and key presses, but the different characteristics of the various devices (e.g. mouse versus touch screen and full-sized keyboard versus compact keyboard versus virtual keyboard) precludes the level of consistency needed for something similar to mouse tracking or keyboard dynamics to produce the identical seed for a key generation algorithm across devices.
Another concern with this issue is that, with many state-of-the-art techniques, it is difficult to convincingly tie the key pair to a specific person/identity, especially in the absence of a trusted 3rd-party to perform the identification & authentication. In particular, if it is required that Alice digitally sign a document, the authentication server can send an e-mail with a link to the document and a password to the document to Alice's e-mail account. With this, all the security for this signing scheme rests on the security of Alice's email account password. Anyone that can ferret out her email account password can login to the authentication server as Alice and sign the document. Note that sending the document link and the login password as two separate e-mails does nothing to help this situation.
Furthermore, when someone logs into the authentication server, that person generates a key pair and thereby informs the server what their public key is. Therefore, it is possible that two users could have the same public key. If each user generates his/her own key pair, such a collision is highly unlikely to happen, but it is certainly possible that (1) Alice logs in as Bob (e.g., by learning his e-mail password; see above) and submits her own public key as his, or (2) Alice logs in as Alice and submits Bob's public key as her own. In the first scenario, Alice will be able to repudiate any signature she has created (claiming that Bob must have signed it). In the second scenario, Alice will be able to submit any document that Bob has signed to receive something (for example, his digital endorsement signature on the “back” of an electronic cheque) and receive that thing herself. In either scenario, the credibility of the digital signature system is undermined and the system will not be used.
Thus, what is required is (a) a more reliable way to generate key pairs, and (b) a more reliable way to bind the public key to a specific person and to ensure that duplicate public keys are avoided.
There is therefore a need for systems, methods, and devices that mitigate if not overcome the limitations of the prior art.